README: describe the real Publish process - #58
Conversation
The Publish section still described the pre-June-2026 tag-triggered process and linked .github/workflows/publish-soldeer.yaml, which does not exist. Rewritten against the actual files: every push to main runs .github/workflows/package-release.yaml, which delegates to rainix's rainix-autopublish reusable; the version is foundry.toml's [external.package].version (the next unpublished version), gated on packaged content differing from the newest published zip, with the version line rewritten after publishing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 33 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Closing per human ruling (2026-08-19): rainlanguage/rainix#333 changes the publish semantics this README text describes; the README gets rewritten once under the new behavior when that lands. |
1 participant
Fixes the README's stale Publish section (no issue; ordered directly by the human 2026-08-19 — the pre-June-2026 process was still documented).
What was wrong: the section said publishing is triggered by tagging
v<x.y.z>onmainand linked.github/workflows/publish-soldeer.yaml, which does not exist.What it says now (each claim verified against
.github/workflows/package-release.yamland therainix-autopublishreusable in rainlanguage/rainix @main):mainrunsPackage Release(.github/workflows/package-release.yaml), which callsrainix-autopublishwithsoldeer-package: rain-datacontract(the name is passed explicitly, not derived from the repo name).foundry.toml's[external.package].version, the NEXT unpublished version.rainix-static soldeer-gate) publishes only when the packaged content differs from the newest published zip; on publish it tagssol-v<version>, creates a GitHub release, and rewrites the version line to the next unpublished version in aPackage Releasecommit, which the workflow's job guard skips when that push re-triggers it.Rest of the README read in full: no other sentence contradicts the real process (Install and Develop sections are unaffected).
QA
.github/workflows/package-release.yamlin this repo andrainix-autopublish.yamlat rainlanguage/rainix@main, read directly; every README claim traced to a workflow step🤖 Generated with Claude Code